Методические рекомендации на курсовую работу по теме "Базы данных" содержание методические рекомендации на курсовую работу по теме "Базы данных" 1 содержание 1 Общие положения курсовой работы 1 Организация


Скачать 469.11 Kb.
НазваниеМетодические рекомендации на курсовую работу по теме "Базы данных" содержание методические рекомендации на курсовую работу по теме "Базы данных" 1 содержание 1 Общие положения курсовой работы 1 Организация
страница4/4
ТипМетодические рекомендации
1   2   3   4

6. Технология выполнения курсовой работы

6.1.1. Системный анализ


Процесс проектирования баз данных начинается с анализа требований к системе, которые чаще всего изложены в свободной форме, требуют дополнительных ограничений и уточнений. На этом этапе требуется четко сформулировать цели разработки, определяются специфичные требования к базе данных, вытекающие из этих целей или сформулированные непосредственно заказчиком.. В результате выполнения данного этапа должны быть определены:

    • основные информационные объекты, которые фигурируют в системе и могут быть выявлены сразу на данном этапе;

    • группы пользователей, которые будут работать с системой и их функции по работе с системой и БД;

    • описаны базовые алгоритмы обработки информации в системе;

    • выявлены информационные процесса статические, которые могут быть смоделированы путем внесения или изменения данных в базу данных и динамические, которые требуют алгоритмического разрешения.

Например, если нам требуется вносить в базу данных сведения о клиентах и при этом проверять возраст клиента, то мы этот процесс можем реализовать как статический, но для проверки повесим правило контроля возраста при вводе данных. Это правило может быть описано декларативно и присоединено к атрибуту дата рождения при создании соответствующей таблицы.

Однако, если нам требуется проверять по ряду атрибутов (дате рождения, номеру и серии паспорта) не был ли ранее занесен в базу данных данный клиент, то эти действия требуют алгоритмической проверки. Необходимо будет написать триггер или хранимую процедуру, которая бы выполнялась каждый раз при вводе нового клиента.

6.1.2. Концептуальное проектирование


Следующим этапом является собственно концептуальное проектирование.

Результатом этого этапа является высокоуровневое представление информационных требований, например, такое как диаграмма «сущность-связь» (ER-диаграмма). Общим для всех подходов к построению ER-диаграмм является набор из четырех основных проектных решений или шагов:

    1. Определение сущностей.

    2. Определение атрибутов сущностей.

    3. Идентификация ключевых атрибутов сущностей.

    4. Определение связи между сущностями.

Требования каждого пользователя анализируются и представляются в некоторой общей форме. Объекты и события, ассоциированные с представлением каждого пользователя, моделируются множеством сущностей, атрибутов и связей между сущностями. В дальнейшем эти требования сливаются в единое глобальное представление.

В большинстве случаев пользователи описывают свои информационные требования в терминах сущностей, атрибутов и связей. Сущность представляет собой основное содержание того явления или процесса, о котором необходимо собрать информацию. В качестве сущности может выступать личность, место или вещь, информацию о которой надо хранить. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных предметов или вещей, выступающему как целое. Экземпляр сущности относится к конкретной вещи в наборе. Средством, с помощью которого определяются свойства сущностей, являются атрибуты. Атрибут – это поименованная характеристика сущности. Атрибут имеет следующие характеристики:

    • Наименование. Уникальное обозначение атрибута.

    • Описание. Повествовательное изложение смысла атрибута.

    • Роль. Конкретное использование атрибута.

Выделение сущностей является процессом слабо формализованным и творческим. При выделении сущностей мы выполняем требования нормализации, которые используются при проектировании реляционных баз данных. Одна сущность моделирует некоторый класс однотипных объектов. Рассмотрим пример, допустим нам необходимо промоделировать описание клиентов нашего банка. Каждый клиент характеризуется рядом параметров-атрибутов, описывающих клиента. Такими атрибутами могут выступать ФИО, дата и место рождения, характеристика паспорта, ИНН, семейное положение, домашний адрес, место работы и должность, образование, средняя заработная плата (нам ее необходимо знать в случае предоставления кредита), и другие характеристики, если они нам необходимы. А почему мы используем в качестве атрибута «Дату рождения», а не возраст? Нам при определении кредитоспособности клиента требуется знать возраст, именно он определяет, находится клиент в предпенсионном возрасте или нет. Действительно нам необходимо знать возраст, но возраст человека меняется с каждым днем, а дата рождения остается неизменной, и, зная дату рождения, мы в любой момент можем вычислить возраст с точностью до дня.

Если мы с Вами используем для моделирования Case -систему Power Designer, то можем получить следующую схему сущности «Клиенты» (см. рис. 1):



Рис.1. Первое приближение сущности «Клиенты».

Теперь необходимо провести подробный анализ данной сущности. Прежде всего, необходимо определить тип данных для каждого атрибута. При хранении информации в базе данных СУБД контролирует допустимость определенных действий по работе с конкретными данными, так символьные строки нельзя складывать и умножать, а числа можно. Ряд арифметических операций допустим и для данных типа дата. Есть данные типа денежных единиц, у них свои шаблоны представления. Есть числовые данные целые и действительные. Когда мы задаем каждому атрибуту конкретный тип данных, тем самым мы заставляем СУБД проводить дополнительный контроль при вводе данных, на соответствие их заданному типу, так если вводимые данные является целыми числами, то система не позволит внести туда строковые данные.

Кроме того, что каждому атрибуту мы должны определить стандартный тип данных, нам необходимо указать обязательный этот атрибут или необязательный. Свойство обязательности определяет, что данный атрибут всегда имеет конкретное значение, не может быть экземпляр сущности, для которого этот атрибут не задан. Свойство обязательности задается проставлением галочки в позиции «М» (mandatory) в интерфейсе описания атрибутов сущности.

Каждый экземпляр сущности уникален, его необходимо однозначно идентифицировать в системе, это значит, что для данной сущности существует некоторый набор атрибутов, значения которого однозначно определяют экземпляр сущности. Например в нашем случае это атрибуты описывающие паспорт. Это 4 атрибута: серия паспорта, номер, кем выдан и когда выдан. Однако наборов атрибутов, которые однозначно идентифицируют экземпляр сущности, может быть несколько. В нашем случае ИНН – также должен однозначно идентифицировать клиента. Оба этих набора претендуют на роль первичного ключа ( Primary Key ). Первичный ключ используется для наиболее быстрого обращения к экземпляру сущности. Мы видим, что один первичный ключ состоит только из одного атрибута, а второй состоит из 4-х различных атрибутов. Конечно, разумнее писать запросы с одним условием, поэтому выберем в качестве первичного ключа ИНН. Теперь наша сущность «Клиенты» на схеме будет выглядеть следующим образом (см. рис.2):



Рис. 2. Сущность «Клиенты» после определения типов данных для атрибутов и задания первичного ключа.

Типы данных мы выбираем из стандартного набора данных, которые поддерживает язык SQL . На рис. 3 представлена панель со стандартными типами данных, которые предлагает PowerDesigner .

Большинство типов данных понятны интуитивно и не вызывают дополнительных вопросов, однако обратим внимание на некоторые особенности. Прежде всего для целых числе предложено 3 типа: interger – это целое число, которое получатся при 4-х байтном хранении, short integer – целое при 2-х байтном представлении (от -32677 до +32677), long integer – целое при 8-ми байтном представлении, и наконец есть однобайтное целое byte – т. е. до 255.

Числовой тип Number используется в некоторых серверах, чаще всего он интерпретируется как числовое поле без дополнительных ограничений. Тип данных decimal, float, short float, long float – соответствуют действительным числам с разной точностью. Тип данных Serial используется для представления инкрементных полей. Так, для СУБД MS Access – этот тип данных соответствует счетчику, а для MS SQL Server 2000 – это уже поле со свойством Identity, а для сервера MySQL – это будет поле типа AUTO_INCREMENT.



Рис. 3 Стандартные типы данных.

Тип данных Characters – соответствует символьной строке, в которой всегда присутствует одно и тоже определенное количество символов, заданное в характеристике length. Тип Variable characters отличается тем, что значениями этого типа могут быть строки, длина которых не превышает заданную, но может быть и меньше. В большинстве случает применение типа Variable characters предпочтительнее, т.к. в этом случае СУБД не дополняет значение пробелами или нулями или другими символами, она сохраняет всегда только то число символов, которое занесено в БД. Особенно важно это при выполнении операции поиска и сравнения.

Тип данных Long characters и Long var characters применяется для тех СУБД, которые поддерживают строковые данные, превышающие стандартную максимальную длину в 255 байт, определенную для данного типа. Например в СУБД Oracle могут быть символьные строковые данные более 2000 байт.

Тип данных Text – соответствует неструктурированным данным, которые хранятся в отдельных файлах и соответствуют в физических структура типам BLOB (binary large object) или m e mo поле в MS Access . Эти данные не имеют никаких ограничений по размеру, однако требуется с большой осторожностью относится к назначению данного типа данных, работа с подобными данными затруднена и происходит гораздо медленнее.

Данные типа Dat e соответствуют представлению текущих календартных дат. Тип данных Dat e & Time – кроме даты включает еще и представление времени, тип данных. Тип данных Time – соответствует представлению времени. Следует отметить, что этот тип данных не во всех СУБД реализован, так в MS SQL Server 2000 и Ms Access подобного типа нет.

Последний тип данных в рамках стандартного перечня – timestamp. Этот тип данных соответствует некоторому представлению системного времени. Так же как и инкрементные данные эти значения присваиваются системой и не могут быть введены пользователем. Для типа данных timestamp допустимо сравнение, т. е. его значения строго упорядочены. Часто данный тип может быть использован для того, чтобы определить, какая из строк была введена ранее.

Мы назначили всем атрибутам соответствующие типы данных, задали обязательность для ряда атрибутов, определили первичные ключи. Но теперь нам стоит подумать, а все ли введенные атрибуты действительно соответствуют нашей созданной сущности, нет ли здесь ситуации, когда мы несколько сущностей объединили в одну. Действительно, каждый клиент может менять со временем семейное положение, у него изменяется средняя заработная плата, и даже место работы может измениться в течение того срока, пока он выплачивает наш кредит. Разумеется может измениться и его образование. Мы выяснили, что ряд атрибутов моделируют другие сущности, они описывают динамически изменяемые ситуации, связанные с нашим клиентом. Поэтому резонно будет создать дополнительно 3 сущности, одну связанную с работой, вторую с изменениями в образовании и третью с изменениями в семейном положении. При этом все три сущности связаны с главной сущностью «Клиенты». Пока определим набор атрибутов для каждой сущности и потом уже зададим связи (см. рис. 4).



Рис. 4. Декомпозиция сущности «Клиенты».

При анализе рис.4 мы видим, что разбиение нам пришлось сделать не на 4 сущности, а на 5. Почему такое получилось. При выделении атрибутов, связанных с работой мы подумали. Что в одной и той же организации клиент может перемещаться по служебной лестнице, при этом у него меняются такие важные для нас атрибуты как должность и средняя заплата. Именно поэтому мы введи дополнительно сущность, которую назвали «Перемещение по работе» и в ней отражаем изменения, которые связаны с продвижением по служебной лестнице в рамках одного места работы. В каждой вновь введенной сущности мы определили первичный ключи, расширили список атрибутов. Для атрибутов сущности можно задать ряд проверочных ограничений. Например, заработная плата должна быть всегда положительным числом. Для задания подобного ограничения, необходимо перейти в сущности в экран описания атрибуты, выбрать пиктограмму «Свойства» и перейти в экран задания конкретных ограничений (см. рис.5):



Рис. 5. Окно списка атрибутов сущности.

Теперь переходим в экран конфигурирования свойств для атрибута «Средняя заработная плата» (см. рис. 6):



Рис. 6. Задание дополнительных ограничений атрибуту Salary.

При задании ограничений для атрибутов необходимо помнить, что мы можем задать стандартные ограничения (см. рис.7) или дополнительные. В рамках стандартных ограничений мы можем задать граничные условия (Minimum и Maximum), перечислимый список допустимых значений, который задается в области List values, значение по умолчанию, если оно равно некоторой константе.

 



Рис. 7. Окно задания стандартных ограничений.

Однако существует ли возможность учета дополнительных ограничений, которые мы накладываем на значения отдельных атрибутов или на строки (экземпляры) сущностей. Да, при проектировании инфологической модели с использованием инструментальной среды PowerDesigner существует возможность задания подобных ограничений. Эти ограничения носят специальное название, они называются проверочными (Check) и могут относиться либо к атрибуту либо к сущности целиком. Опишем словесно ряд ограничений. Прежде всего хотелось бы, чтобы система поддерживала ограничение уникальности возможного ключа для сущности «Клиенты». Для этого выделяем сущность «Клиенты», выбираем из контексного меню свойства (properties) и переходим на закладку идентификаторы (identifiers) (см. рис.8):



Рис. 8. Закладка Identifiers для сущности «Клиенты».

Теперь выбираем из верхнего меню пиктограмму «Добавить», добавляем новый идентификатор, сохраняем его, нажав на кнопку «Применить» и переходим к описанию вновь созданного идентификатора (см. рис. 9), для этого также нажимаем пиктограмму «Добавить» уже в новом всплывающем окне (см. рис. 10) и в этом окошке отмечаем набор атрибутов, описывающий паспорт, который и составляет второй возможный ключ.



Рис. 9. Установка дополнительного ограничения на уникальность набора атрибутов.

Для того, чтобы нам учесть временную последовательность, т. е.

То, что дата начала работы в должности всегда раньше даты окончания работы в этой же должности, или дата начала обучения раньше даты окончания необходимо создать специальные правила, в которых эти ограничения будут сформулированы и прикрепить эти правила к соответствующим сущностям. Для этого перейдем в верхнее меню, выберем Model-> B u sinress Ru le s b yf ; fnm gbrnjuhfvve «Добавить», появится новое правило Rule_1,для него нажимаем пиктограмму «Свойства» (см. рис. 10) и переходим в экран формулировки правила. Выбираем закладку Expressions и формулируем выражение, которое должно проверяться при вводе каждой новой строки или при измени данных в этой строке.

Date_e_d Is Null OR Date_e_d > Date_b_d

Если перевести на русский язык, то мы потребовали, чтобы дата окончания работы в должности была бы неопределенной (не заданной) или она была бы больше, чем дата начала работы в этой же должности. (см. рис. 11). Это ограничение будет выполняться на сервере.



Рис. 10. Окно формирования Правил-ограничений.



Рис. 11. Формулировка правила-ограничения.

Теперь желательно задать для этого ограничения некоторое естественно воспринимаемое название и записать его в область Name, оставив Code правила именованным по правилам SQL (см. рис.12).



Рис. 12. Изменения названия у ограничения.

Теперь прикрепим это правило к соответствующей сущности. Для этого откроем закладку Rules у сущности и выберем пиктограмму «Добавить». Проставляем галочку против выбранного правила и нажимаем «ОК» (см. рис.13), а потом «Применить» в окне списка правил.



Рис. 13. Прикрепление правила к сущности.

Сформировав все правила-ограничения для всех сущностей, мы можем переходить к формированию связей.

Связи отражают взаимосвязь между экземплярами сущностей. В классической модели «Сущность-связь» бывают 3 типа связей:

    • «Один к одному», когда каждому экземпляру одной сущности соответствует один экземпляр другой сущности. Это нежелательные связи, потому что в этой ситуации возникает законный вопрос, если у вас так тесно взаимосвязаны сущности, то почему их просто не объединить в одну? В очень редких ситуациях удается грамотно обосновать подобные связи. Чаше всего это связано с тем, что фактически мы пытаемы смоделировать некоторую суперсущность и ее подсущности. И в этом случае у нас есть некоторый набор характеристик, которые присутствуют всегда у каждого экземпляра сущности, но есть еще и некоторый набор характеристик, которх нет в ряже экземпляров сущности. Например, преподаватель может иметь ученую ступень и ученое звание, а может не иметь данных характеристик. Если он имеет их, то эти характеристики сопровождаются указанием номеров соответствующих документов (дипломов и аттестатов), дат их утверждения или выдачи, в противном случае этих характеристик нет. Если подобных дополнительных необязательных характеристик немного, то резонно использовать одну сущность, но если число этих дополнительных характеристик существенно превышает число основных, то наверное имеет смысл представить эту ситуацию в виде двух сущностей, связанных связью «один к одному», обязательной с одной стороны и необязательной с другой стороны.

    • «Один ко многим» - эта связь отображает иерархические отношения между сущностями и является наиболее распространенной. Эта связь моделирует отношение родительской и подчиненной сущностей. Данная связь означает, что экземпляр родительской сущности связан с несколькими экземплярами подчиненной сущности. В нашем случае подобные связи могут быть заданы для связи сущностей «Клиенты» и «Работа», «Работа» и «Перемещение по службе». Действительно у одного клиента может быть несколько мест работы, а на одном месте работы он может несколько раз перемещаться по служебной лестнице.

    • «Многие ко многим» - этот тип связи определяет такие отношения между экземплярами сущностей, когда один экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности и наоборот, один экземпляр второй сущности может быть связан с несколькими экземплярами первой. Например, один студент учится у нескольких преподавателей, но и один преподаватель преподает множеству студентов. Однако при более глубоком рассмотрении вопроса, чаще всего данный тип связи имеет еже дополнительные характеристики-атрибуты, поэтому возникает промежуточная связующая сущности, которая развязывает данный тип связи. Например, преподаватель и студент связаны расписанием занятий, и получается, что студент имеет множество занятий и преподаватель имеет множество занятий. Поэтому связь «Многие ко многим» преобразовалась в 2 связи «Один ко многим».



Рис. 15 Палитра инструментов.

Кроме трех базовых типов связи имеют характеристику обязательности и необязательности. Каждая связь может быть обязательной с одной стороны и необязательной с другой стороны. Обязательность связи отмечается перечеркиванием ее, а необязательность – наличием пустого кружка на конце связи. Обязательная связь требует обязательного наличия экземпляров связываемых сущностей. Это определяется семантикой взаимоотношений. Например, связь между работой и перемещением по службе обязательная с двух сторон, потому что не может быть работы без первой же должности и не может быть должности в отрыве от конкретного места работы. При задании связи мы выбираем из палитры инструментов пиктограмму «Relationship» (см.рис.15) и тянем ее от одной сущности к другой. Далее мы попадаем в окно конфигурирования свойств связи (см. рис. 16).

 



Рис. 16. Окно конфигурирования связи.

Здесь можно задать название и код связи, как для любого моделируемого объекта, определить тип связи и задать ее обязательность (Checkbox Mandatory) и обязательно нажимаем кнопку «Применить», чтобы эти свойства были бы закреплены за данной связью. Дополнительно можно описать роль связи, это текст, поясняющий ее назначение, он не будет преобразовываться в скрипт на языке SQL.

Кроме указанных свойств существует еще понятие Зависимости (Dependen t) для связи. Свойство зависимости определяет ключевую связь, т. е. такую, которая при переходе к реляционной модели обеспечит создание составного первичного ключа подчиненной таблицы. Действительно, у каждого клиента могут свои перечни мет работы, свои ступени в образовании и семейном положении. Поэтому мы нумеруем эти позиции внутри каждого клиента, т. е. существует первое место работы для данного клиента, и таких первых мест будет столько сколько клиентов у нас есть. Для получения зависимого типа связи необходимо поставить галочку в поле Dependent. У нас все связи резонно сделать зависимыми. После простановки связей наш фрагмент превратился в следующую схему (см. рис.17):



Рис. 17 Фрагмент ER-модели.

Следующим этапом разработки является проверка концептуальной модели на корректность. Для выполнения проверки выбираем пиктограмму Check Model (см. рис. 18):



Рис. 18. Часть верхнего меню системы.

После проверки Вы получаете список ошибок (error(s)) или предупреждений (warning (s)) и окно с описанием полученных сообщений Result list (См. рис. 19):



Рис. 19. Список предупреждений.

В нижнем окне системы вы получаете тест сообщений о выполненных проверках и, главное, результирующее сообщение и корректности созданной модели, например следующее:

0 error(s), 3 warning(s).

The Conceptual Data Model is correct, no errors were found.

Данное сообщение означает, что серьезных ошибок в созданной моджели нет и в общем случае можно переходить к следующему этапу проектирования – трансляции в физическую модель конкретной СУБД. Однако я настоятельно рекомендую расшифровать предупреждения, чаще всего их можно легко устранить. Например, в нашем случае в предупреждениях говорится о том, что есть атрибуты, которые не задействованы ни в одной сущности. Такое часты бывает, если Вы переделывайте проект, убирая одни атрибуты и добавляя другие. Действительно мы сначала в сущности «Клиенты» имели атрибуты: образование, семейное положение, место работы, но расширив модель мы эти атрибуты убрали из сущности и они не виды нам, но из общего хранилища модели, называемого репозитарием, мы их не убрали. Это легко сделать, для этого надо в верхнем меню выбрать Model -> Data Items и перейти в окно общего списка атрибутов модели (см. рис.20)



Рис. 20. Общий список атрибутов модели.

Теперь по очереди устанавливаем курсор на каждый неиспользуемый атрибут и нажимаем пиктограмму «Удалить». После этого мы выполняем повторную проверку и получает сообщение о корректности схемы с указанием желанного сообщения 0 error(s), 0 warning(s).

6.1.3. Трансляция в физическую модель для выбранной СУБД


Для переходя к физической модели в верхнем меню выбираем

Tools -> Generate Phisical Data Model … и попадаем в окно выбора СУБД (см. рис.21):



Рис. 21. Выбор СУБД

Раскрыв combobox со списком поддерживаемых СУБД выберите MS SQL Server 2000. Желательно задать имя (Name) и код (Code), отличные от имени и кода концептуальной модели. После нажатия кнопки «Применить» Вы попадаете в окно физической модели (см. рис. 22).

Если Вы выполнили предварительную проверку, то чаще всего преобразование происходит без ошибок. Однако возможно получение и некоторого списка ошибок, которые необходимо устранить. Все неточности или ошибки устраняются на возможно раннем этапе проектирования, т. е. в нашем случае это концептуальное проектирование.

В физической схеме проверьте корректность добавления внешних ключей ( Foreign Key). Внешние ключи в таблицах отмечены признаком fk , первичный ключ отмечается признаком pk и на нашей схеме первичные ключи подчеркиваются. Так как все наши связи зависимые (ключевые), то первичные ключи в 4-х подчиненных таблицах теперь составные, они состоят из двух атрибутов, хотя все первичные ключи в концептуальной модели в соответствующих сущностях состояли только из одного атрибута. В нашей модели не появилось новых таблиц, это произошло потому, что у нас не было ни одной связи типа «Многие ко многим». Проверим трансляцию правил, которые мы задали в концептуальной модели. Для этого перейдем в верхнее меню, выберем Model -> Busines Rules и перейдем в список правил, которые преобразованы уже в ограничения физической модели (см. рис. 23).



Рис.22 Физическая модель для MS SQL Server

В нашем примере оба правила, которые мы создали, преобразованы в физическую модель.



Рис. 23. Список странслированных правил в физической модели.

Если Вы не увидели в списке правила, которые Вы задали в концептуальной модели, то вернитесь в концептуальную модель и проверьте, какой тип правилам Вы в ней задали. Только правила типа validation транслируются в физическую модель.

6.1.4. Получения скрипта генерации объектов БД на языке SQL команде.


Следующим этапом в проектировании базы данных является этап генерации скрипта на языке SQL. Для подготовки этого этапа переходим в меню, выбираем Databases -> Generate DataBase и попадаем в экран настройки параметров генерации (см. рис.23-26).

 



Рис.23. Страница настройки параметров генерации таблиц.

При генерации таблиц необходимо указать, что мы не задаем в скрипте физические опции, не задаем разрешения по работе с объектами и не используем операцию предварительного удаления таблиц (Drop table). Удаление таблиц может быть использовано в том случае, если Вы предполагаете, что при существовании таблицы с данным именем мы ее сначала удаляем, а потом генерируем по новым параметрам. В общем случае не рекомендуется использовать предварительное удаление таблиц (Drop table), потому что это соответствует более примитивному уровню управления процессом генерации. Вам следует самим понимать все ошибки, которые могут произойти в процессе генерации. Мы не указали, что требуется генерировать представления (View), потому что мы не использовали их в своей схеме. Если Вы используете представления, то следует оставить галочки в соответствующих позициях.



Рис. 24. Настройка параметров генерации первичных и внешних ключей.

Теперь переходим к этапу установки параметров для генерации ключей. Мы отмечаем необходимость включения описания первичных ключей внутри оператора генерации таблицы (позиция inside table). Кроме того, мы указываем, что у нас есть альтернативные (возможные ключи) и мы хотели бы включить ограничения на уникальность в скрипт генерации таблиц. Далее в этом же экране мы указываем, что хотим сгенерировать операторы, поддерживающие добавление ограничений по внешним ключам (foreign key) с принципами поддержки ссылочной целостности (Declarative Integrity), однако отмечаем, что данный тип ограничений должен быть сгенерирован вне основного оператора создания таблицы. Чем это обусловлено? Прежде всего, неизвестным заранее порядком включения операторов создания таблиц. Мы не можем быть уверены, что порядок создания таблиц будет таков, что он будет соответствовать принципу иерархии объектов в БД, при формировании ограничения на внешний ключ, мы должны быть уверены, что родительская таблица уже существует. И последняя закладка связана с описанием параметров генерации всей БД (см. рис. 25).



Рис. 25 Закладка определения параметров генерации собственно БД.

При задании параметров генерации всей БД в скрипте нам будет необходимо исполнять скрипт, находясь в системной БД Master, возможно, что мы не имеем прав по исполнению скриптов в БД Master, поэтому лучше задать параметры, которые обеспечивают исполнение скрипта в уже созданной пользовательской БД, что мы и сделали. В последнем окне желательно так е задать имя, создаваемого скрипта (это просто текстовый файл с расширением sql, которое можно изменить) и место его расположения (см. рис. 26). После нажатия кнопки «Открыть» мы переходим в экран стандартного текстового редактора, заданного в операционной среде, для поддержки данного типа файлов (см. правое окно на рис. 26). Если мы щелкнем по соответствующему окну, оно раскроется, и мы увидим сгенерированный PowerDesigner текст (см. рис.27). Просмотрев текст, мы закрываем окно и переходим к последнему этапу генерации БД.



Рис. 26. Задание параметров сохранения файла с SQL -скриптом создания объектов БД и переход к в окно редактора.



Рис. 27. Текст на языке SQL генерации объектов БД.

6.1.5. Генерация объектов БД на MS SQL Server 2000.


Данный этап начинается с создания новой БД на сервер. Это Вам уже известно (см. практику 4). После создания новой БД переходим в Query Analyzer и в нем открываем файл с сохраненным текстом на SQL и исполняем его (см. рис. 28).



Рис. 28. Загрузка SQL -скрипта создания объектов БД в Query Analyzer

Нажав заветный зеленый треугольничек, мы должны получить в нижнем окне сообщение:

The command(s) completed successfully.

Если мы получили сообщение, отличное от приведенного, то анализируем и исправляем ошибки. Напоминаю, что исправлять ошибки надо в концептуальной модели, а после этого последовательно пройти все этапы:

    • Проверить корректность концептуальной модели;

    • Сгенерировать изменения в физическую модель;

    • Сгенерировать новый SQL – скрипт;

    • В MS SQL Server удалить все созданные таблицы в своей БД;

    • Загрузить в Query Analyzer новый скриипт и выполнить его.

Указанную последовательность выполнять до момента получения требуемого сообщения.

После создания всех объектов перейдем в Enterprise Manager, раскрываем папку с нашей БД, убеждаемся в том, что все таблицы созданы и присутствуют. Теперь переходим к созданию диаграммы, выбираем ссылку diagrams в списке объектов БД и щелкаем по ней. Мы попадаем в мастер построения диаграмм. В следующем окне мастера Вам необходимо указать список таблиц, которые будут входить в новую диаграмму (см. рис. 29).



Рис. 29. Выбор таблиц для генерации диаграммы.

Выбрав все требуемые таблицы запускаем построитель схемы, который их соединяет в соответствии со ссылочной целостностью, которая была определена в SQL -скрипте (см. рис. 30).

 



Рис. 30. Диаграмма, соответствующая созданной БД

Теперь необходимо перейти к таблицам и проверить все созданные ограничения. Первичный ключ можно просмотреть, открыв таблицу в режиме конструктора. Выбрать таблицу, в контекстном меню выбрать Design table (см. рис. 31)

 



Рис. 31. Просмотр свойств таблицы в режиме конструктора.

Если выбрать в верхнем меню пиктограмму «Свойства», то можно увидеть все связи и дополнительные ограничения, заданные для таблицы. Если мы выберем закладку Indexes / keys для таблицы Clients, то кроме стандартного ограничения и индекса по первичному ключу, мы получим еще и дополнительный индекс по ограничению уникальности, который был создан для альтернативного ключа.

6.1.6. Разработка хранимых процедур и триггеров


После получения и проверки корректной схемы БД необходимо приступить к разработке хранимых процедур и триггеров. Порядок описания разрабатываемых объектов следующий:

    1. Описание цели создаваемого объекта, т. е. функционального назначения на естественном языке.

    2. Разработка алгоритма работы разрабатываемого объекта либо с использованием стандартных схем-алгоритмов, либо с использованием словесного алгоритма, который разделяет последовательность действий по шагам и определяет их взаимосвязь.

    3. Приведение текста создаваемого объекта на языке TransactSQL с обязательными комментариями.

    4. Описание режима тестирования созданного объекта. В режиме тестирования должны быть задокументированы с использованием соответствующих скриншотов состояние до использования объекта, состояние после, для визуального контроля правильности исполнения.

6.2. Рекомендуемая литература


    1. Электронный учебно-методический комплекс по дисциплине.

    2. Карпова Т. Базы данных. Модели, разработка, реализация. Учебник. Изд. Питер 2001 г. ISBN 5-272-00278-4

    3. Диго С.М. Базы данных: проектирование и использование. Учебник. Финансы и статистика 2005 г. ISBN   5-279-02571-2






1   2   3   4

Похожие:

Методические рекомендации на курсовую работу по теме \"Базы данных\" содержание методические рекомендации на курсовую работу по теме \"Базы данных\" 1 содержание 1 Общие положения курсовой работы 1 Организация iconВ. Н. Бибило Рекомендации по оформлению курсовой работы
Каждый студент юридического факультета бгу ежегодно выполняет одну курсовую работу, за исключением студентов выпускного курса, которые...

Методические рекомендации на курсовую работу по теме \"Базы данных\" содержание методические рекомендации на курсовую работу по теме \"Базы данных\" 1 содержание 1 Общие положения курсовой работы 1 Организация iconГ. Томска Дидактические материалы по теме "Информационные базы данных. Субд access"
Данный сборник дидактических материалов составлен с целью использования его для работы с одаренными детьми. Уместно включать их и...

Методические рекомендации на курсовую работу по теме \"Базы данных\" содержание методические рекомендации на курсовую работу по теме \"Базы данных\" 1 содержание 1 Общие положения курсовой работы 1 Организация iconУрок с элементами деловой игры "Создание базы данных" Карасенко Татьяна Александровна
Место урока в теме – урок проводится в ходе изучения темы “Информационные системы”, после изучения понятий базы данных, видов баз...

Методические рекомендации на курсовую работу по теме \"Базы данных\" содержание методические рекомендации на курсовую работу по теме \"Базы данных\" 1 содержание 1 Общие положения курсовой работы 1 Организация iconПример создания базы данных «Студенты» Постановка задачи. Выделение...
В окне «Базы данных» выбрать объект «Таблицы», выберите опцию «Создание таблицы в режиме конструктора»

Методические рекомендации на курсовую работу по теме \"Базы данных\" содержание методические рекомендации на курсовую работу по теме \"Базы данных\" 1 содержание 1 Общие положения курсовой работы 1 Организация iconПояснительная записка к курсовой работе по дисциплине «Базы данных»
Метод исследования – моделирование базы данных в программе Microsoft Access 2013

Методические рекомендации на курсовую работу по теме \"Базы данных\" содержание методические рекомендации на курсовую работу по теме \"Базы данных\" 1 содержание 1 Общие положения курсовой работы 1 Организация iconБазы данных
Для признания исключительного права на базы данных не требуется специальной регистрации (однако предпочтительно осуществлять государственную...

Методические рекомендации на курсовую работу по теме \"Базы данных\" содержание методические рекомендации на курсовую работу по теме \"Базы данных\" 1 содержание 1 Общие положения курсовой работы 1 Организация iconУчебное пособие для студентов по курсу «Математика и информатика»
Методические указания по выполнению индивидуального домашнего задания (идз) по теме «Базы данных» 58

Методические рекомендации на курсовую работу по теме \"Базы данных\" содержание методические рекомендации на курсовую работу по теме \"Базы данных\" 1 содержание 1 Общие положения курсовой работы 1 Организация icon«Системы управления базами данных. Формы представления данных. Создание структуры базы данных»
Обучающая: создать условия для усвоения содержания теоретического материала по данной теме на уровне закрепления, научить учащихся...

Методические рекомендации на курсовую работу по теме \"Базы данных\" содержание методические рекомендации на курсовую работу по теме \"Базы данных\" 1 содержание 1 Общие положения курсовой работы 1 Организация iconМетодические указания для выполнения лабораторных работ и «Базы данных»
Лабораторная работа №1 «Организация хранения данных в субд ms access»

Методические рекомендации на курсовую работу по теме \"Базы данных\" содержание методические рекомендации на курсовую работу по теме \"Базы данных\" 1 содержание 1 Общие положения курсовой работы 1 Организация icon«Создание математических моделей» 15
Требования к формированию учебных заданий, проверяемых вручную и заданию на курсовую работу/курсовой проект 20

Вы можете разместить ссылку на наш сайт:


Все бланки и формы на filling-form.ru




При копировании материала укажите ссылку © 2019
контакты
filling-form.ru

Поиск