Этапы создания базы данных

Автор работы: Пользователь скрыл имя, 09 Декабря 2017 в 13:31, реферат

Описание работы

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

Файлы: 1 файл

база данных.docx

— 898.67 Кб (Скачать файл)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

ГЛАВА 2. СТАДИЯ ТЕХНИЧЕСКОГО ПРОЕКТА

 

2.1     Использование  UML для проектирования

Диаграммой классов в терминологии UML называется диаграмма, на которой показан набор классов (и некоторых других сущностей, не имеющих явного отношения к проектированию БД), а также связей между этими классами (иногда термин relationship переводится на русский язык не как “связь”, а как “отношение”). Кроме того, диаграмма классов может включать комментарии и ограничения. Ограничения могут неформально задаваться на естественном языке или же могут формулироваться на языке OCL (Object Constraints Language), который является частью общей спецификации UML, но, в отличие от других частей языка, имеет не графическую, а линейную нотацию.

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

 
Рисунок 2. Пример множественного наследования классов

 

2.2     Организация  входных и выходных данных

Доступ к базе данных осуществляется с помощью  компонента ADO Connection. Для выборки таблиц используются компоненты adoquery и adotable. В свойствах ADO Connection выбираем Connection string, затем записывается путь к базе данных. Далее для каждой таблицы создаются ADO Table1 или adoquery

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

Все не визуальные компоненты осуществляющие связь с базой данных, а это - ADO Table, ADO Connection и Data Source, я разместил на Datamodule, что позволило не закидывать основную форму которые сильно мешали бы при дальнейшим изменении интерфейса программы.

 

 

Рисунок 3. Подключение базы данных

 

2.3     Уточнение  структуры входных и выходных  данных

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

Схема, представленная в приложении А на рисунке А.1 содержит в себе следующие атрибуты:

- «Индекс группы»;

- «Специальность»;

- «Номер курса»;

- «Факультет»;

- «ФИО студента»;

- «ФИО родителей»;

- «Номер комнаты»;

- «Инвентарный номер мебели»;

- «Название мебели»;

- «Место работы родителей»;

- «Нарушения в комнате»;

- «Дата нарушения».

Из приведенной схемы видно, что атрибуты «индекс гр», «№ комнаты» и «год рож.» функционально зависят от атрибута «ФИО студента». Действительно, если учесть, что значения атрибута «ФИО студента» никогда не повторяются, а студент может относиться только к одной из групп, проживать только по одному адресу и иметь только один год рождения, то значения любого из зависимых атрибутов однозначно определяется по «ФИО студента».

Аналогично атрибуты «Специальность» и «Номер курса» функционально зависят от атрибута «Индекс группы», т. к. каждая группа, однозначно идентифицируемая по ее индексу, может обучаться только на каком-то одном курсе и относиться только к одной из специальностей.

В свою очередь, атрибут «Факультет» зависит от атрибута «Специальность», т. к. не существует специальностей, повторяющихся на различных факультетах. Т. е. каждому значению атрибута «Специальность» всегда соответствует только одно значение атрибута «Факультет».

Атрибуты « номер комнаты» и «название мебели». функционально зависит от атрибута «инвентарного номера мебели». Это объясняется следующим. Инвентарный номер мебели уникален, следовательно один и тот же инвентарный номер может быть прикреплен только в одной комнате. Так же один и тот же предмет может иметь только один инвентарный номер.

От ФИО родителей завист ФИО студентов, а место работы и телфоны родителей функционально зависят от ФИО родителей, следовательно и адрес зависит от родителей.

Формирование формы 1НФ

Отношение находится в 1НФ, если все его атрибуты являются простыми (имеют единственное значение). Исходное отношение строится из всех выделенных атрибутов, выделенных в предметной области (рисунок 1).

Первичным ключом исходного отношения является совокупность атрибутов «ФИО родителей», «№ комнаты» и «Инв.номер мебели», так как значения именно этих атрибутов в сочетании друг с другом являются уникальными и никогда в приведенном отношении повторяться не будут.

 

Индекс группы

 

Специальность

 

Курс

 

Факультет

 

ФИО родителей

*

Инв.номер мебели

*

ФИО студента

 

№ комнаты

*

Год рождения

 

№ тел.родителей

 

Место работы

 

Название мебели

 

№ происшествия

Дата

Вид

Адрес


 

 

Рисунок 4. Исходное отношение в 1НФ

 

Формирование 2НФ

Для перевода отношения из 1НФ в 2НФ исключаются из исходного отношения частичные функциональные зависимости неключевых атрибутов

от первичного ключа. В представленном на рисунке 2 отношении в соответствии со схемой функциональных зависимостей присутствуют частичные функциональные зависимости атрибутов «№ комнаты»,

«Индекс группы», «Год рождения» от атрибута «ФИО студента», «№ комнаты», Название мебели» от атрибута «Инвентарный №», «ФИО студента», «№ телефона», «Место работы» от атрибута «ФИО родителей», «Курс», «Специальность», «Факультет» от атрибута «Индекс группы», «Дата происшествия», «Вид происшествия», «№ комнаты» от атрибута «№ происшествия». Для исключения этой зависимости по правилам декомпозиции исходное отношение R разбивается на шесть отношения R1 («ФИО студента», «Индекс группы», «№ комнаты», «Год рождения»), R2(«№ комнаты»), R3 («Индекс группы», «Курс», «Специальность», «Факультет»), R4(«ФИО родителя», «ФИО студента», «Место работы», «№ телефона»), R5(«Инвентарный №», «Название мебели», «№ комнаты»), R6(«№ происшествия», «Дата происшествия», «Вид происшествия», «№ комнаты»). На рисунке 3 представлена декомпозиция по атрибутам «ФИО студента», «№ комнаты», «ФИО родителя», «№ происшествия», «Инвентарный №», «Индекс группы».

 

Рисунок 5. Схема отношений во 2НФ

 

Формирование 3НФ и 3НФБК

Отношение находится в ЗНФ, если оно находится в 2НФ и каждый не ключевой атрибут не транзитивно зависит от первичного ключа. Отношение находится в НФБК, если оно находится в ЗНФ, и в нем отсутствуют зависимости ключей (атрибутов составного ключа) от не ключевых атрибутов.

Атрибут С зависит от атрибута А транзитивно (существует транзитивная функциональная зависимость), если для атрибутов А, В, С выполняются условия А→В и В→С, но обратная зависимость отсутствует

В полученных отношениях R1-R6 существуют частичные зависимости. Для этого требуется исключить их. В отношении R3 атрибут «Факультет», частично зависят от атрибута «Специальность. В результате атрибут «Индекс группа» делится на два отношения R3(«Индекс группы», «Курс», «Специальность») и R7(«Специальность», «Факультет»). В результате схема БД, доведенная до 2НФ выглядит, как представлено на рисунке 4. Так как в полученной схеме отсутствуют транзитивные зависимости, то не будет существовать 3НФ. Более того, поскольку во всех полученных отношениях все функциональные зависимости сводятся к полной нечастичной зависимости от первичного ключа (т. е. отсутствуют зависимости частей составных первичных ключей от неключевых атрибутов) эта схема удовлетворяет всем требованиям НФБК и является конечным результатом концептуального проектирования.

 

Рисунок 6. Отношение в 3НФ и в НФБК

 

2.4     Определение  алгоритма решения задачи

Данная программа предназначена для разных пользователей. После запуска программы происходит подключение модулей (блок 2). Вход в БД происходит через главную форму (блок 3). Если вход выполняется в базу «Группы» (блок 4), тогда можно открыть форму «Группы» (блок 5), либо открывается база «Комнаты» (блок 6,7). Если же происходит нажатие кнопки «Добавить» ( блок 8), то осуществляется добавление записи в БД(блок 9).

Если нажата кнопка «Удалить» ( блок 10), то выбранная запись удаляется с БД(блок 11). При нажатии кнопки «Изменить» (блок 12), осуществляется изменение записи в БД (блок 13). Нажатие кнопки «Сохранить» (блок 14), приводит к сохранению записи в БД (блок 15). Если вход выполняется в базу «Все студенты» (блок 16), открывается форма «Все студенты» (блок 17).

Если необходимо посмотреть «Отчет» студентов по группам (блок-схема 18), то формируется отчет (блок 19). После формирования отчета можно вернуться на главную форму (блок20), либо завершить работу программы (блок 21).

Блок-схема данного процесса представлена в приложении Б на рисунке Б.1.

 

2.5     Определение  формы представления  входных  и выходных данных

Database Desktop - это утилита, во многом похожая на Paradox, которая поставляется вместе с Delphi для интерактивной работы с таблицами различных форматов локальных баз данных - Paradox и dBase, а также SQL-серверных баз данных InterBase, Oracle, Informix, Sybase (с использованием SQL Links).

Для создания новой таблицы следует выбрать пункт меню File > New > Table. При этом будет предложено выбрать тип создаваемой страницы, по умолчанию предлагается формат Paradox 7. Сразу после подтверждения выбранного типа откроется окно определения структуры таблицы, в котором и производятся все необходимые действия, связанные с созданием и определением параметров таблицы, включая ее поля, индексы, пароли, условия и ограничения на значения и для ссылочной целостности.

Процесс создания таблиц и результаты показаны на рисунке 7.

 

Рисунок 7. Database Desktop.

 

В БД содержится 7 таблиц, связанных между собой:

Sudent (Студент);

Komnats(Комнаты);

Proiwestvya (Проишествия);

Roditel (Родитель).

Facultet (Факультет)

Gruppa (Группа)

Mebely (Мебель)

Для создания таблиц использовались типы:

Alpha — строковое поле (A);

Autoincrement – поле счетчик (+);

Short – вещественные числа (S)

Date- дата(D)

Таблица Student (Студент) содержит поля:

FIOst (A)*;

IDgroup(A);

Adress (A);

Komnata(S);

God_rojd(D).

Таблица Facultet (Факультет) содержит поля:

Spec (A)*;

Facultet (A)

Таблица Roditel (Родитель) содержит поля:

FIOrod (A)*;

Mesto_rab (A);

Nomer_tel (A);

FIOst(A);

Таблица Gruppa (Группа) содержит поля:

IDgroup (A)*;

Kurs (S);

Spec (A);

Таблица Komnats (Комнаты) содержит поля:

1. Komnata (S)*;

Таблица Mebely (Мебели) содержит поля:

Invent_nomer (A)*;

Nazv_mebel (A);

Komnata (S);

Таблица Proiwestviya (Проишествия) содержит поля:

Nomer_prois(+);

Vid_prois;

Komnata;

 

Рисунок 8. Создание таблицы Student.

 

Рисунок 9. Создание таблицы Facultet.

 

Рисунок 10. Создание таблицы Roditel.

 

Рисунок 11. Создание таблицы Gruppa.

 

Рисунок 12. Создание таблицы Komnata.

 

Рисунок 13. Создание таблицы Mebely.

 

Рисунок 14. Создание таблицы Proiswestvie.

 

Для создания вторичных индексов используется меню «Secondary Indexes» в выпадающем списке «Table Properties», как показано на рисунке 15.

Рисунок 15. Создание вторичных индексов.

 

Для создания связей между таблицами Student, и Komnats используется меню «Referential Integrity» в выпадающем списке «Table Properties» . Далее необходимо нажать кнопку «Define» и в открывшемся окне выбрать слева поле Komnata, а справа нажать по файлу таблицы Komnats.db как показано на рисунке 16.

 

Рисунок 16. Создание связи между таблицами Student и Komnats.

 

Аналогичным образом создаются связи между таблицами Mebely и Komnats по полю «Komnata», Proiwestie и Komnats по полю «Komnata», Student и Gruppa по полю «IDgroup», Roditel и Student по полю «FIOstudent», Facultet и Gruppa по полю «Special». В базе данных используются всего шесть связей.

 

2.6     Определение  структуры файлов базы данных

В Delphi проблема передачи в программу информации о месте нахождения файлов базы данных решается путем использования псевдонима базы данных. Псевдоним (Alias) - это короткое имя, поставленное в соответствие реальному, полному имени каталога базы данных. Такой псевдоним должен быть зарегистрирован в файле конфигурации конкретного компьютера при помощи утилиты BDE Administrator.

Для доступа к информации программа, обеспечивающая работу с базой данных, подключается библиотека Borland Database Engine (BDE), которая, в свою очередь, использует конфигурационный файл, содержащий информацию обо всех зарегистрированных в системе псевдонимах.

Создается новый псевдоним базы данных. Запускается утилиту BDE Administrator. Выбирается в главном меню элемент Object | New. В появившемся окне (рисунок 17) оставляется тип создаваемой БД без изменений (STANDARD) и нажимается OK. Задается имя псевдонима – Labka.

 

Рисунок 17. Результат создания псевдонима

 

 

2.7     Разработка  структуры базы данных

Разработка приложений баз данных осуществляется посредством использования среды программирования Delphi7.

Главная форма имеет три кнопки управления: “Комнаты”, “Все студенты” и кнопка «Группы». На рисунке 18 представлена главная форма.

Информация о работе Этапы создания базы данных