Проектирование БД, этапы и виды проектирования. Физическая организация БД

МИНИСТЕРСТВО ОБРАЗОВАНИЯ  РЕСПУБЛИКИ БЕЛАРУСЬ

БЕЛОРУССКИЙ НАЦИОНАЛЬНЫЙ ТЕХНИЧЕСКИЙ  УНИВЕРСИТЕТ

 

МЕЖДУНАРОДНЫЙ ИНСТИТУТ ДИСТАНЦИОННОГО ОБРАЗОВАНИЯ

Кафедра « ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ В УПРАВЛЕНИИ »

 

 

 

Контрольная работа по дисциплине « Компьютерные информационные технологии » на тему « Проектирование БД, этапы  и виды проектирования. Физическая организация БД » 

Вариант №14.

 

 

 

 

      Подготовила студентка 2 курса группы №417510

Королёва А.В.

Проверила                                           Монич Ю.И.

 

 

Минск 2011г.

Содержание.

Проектирование БД, этапы  и виды проектирования                              3

Физическая организация  БД                                                                     8

Список использованной литературы                                                       10

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

      Проектирование БД. Этапы и виды проектирования.

База данных (БД) – совокупность самостоятельных материалов (статей, расчетов, нормативных актов и иных подобных материалов), систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины. База данных обрабатывается только в вычислительной системе. Таким образом, любые внекомпьютерные хранилища (архивы, библиотеки, картотеки) базами данных не являются.

Проектирование баз данных – процесс создания схемы базы данных и определения необходимых  ограничений целостности. Основными  задачами проектирования являются:

• обеспечение хранения в базе данных всей необходимой информации;
• обеспечение возможности получения данных по всем необходимым запросам;
• обеспечение избыточности и дублирования данных;
• обеспечение целостности данных (исключение противоречий в содержании данных, их потери и т.д.).

При этапном проектировании баз данных можно выделить следующие  этапы работы.

1. Постановка задачи.

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

2. Анализ объекта.

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

3. Синтез модели.

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

4. Выбор способов представления информации и программного инструментария.

После создания модели необходимо, в зависимости от выбранного программного продукта, определить форму представления  информации. В большинстве систем управления базами данных (СУБД) данные можно хранить в двух видах:

• С использованием форм;
• Без использования форм.

Форма – это созданный  пользователем графический интерфейс  для ввода данных в базу.

5. Синтез компьютерной модели объекта.

В процессе создания компьютерной модели можно выделить некоторые  стадии, типичные для любой СУБД.

Стадия 1. Запуск СУБД, создание нового файла базы данных или открытие созданной ранее базы.

Стадия 2. Создание исходной таблицы или таблиц.

Создавая исходную таблицу, необходимо указать имя и тип  каждого поля. Имена полей не должны повторяться внутри одной таблицы. В процессе работы с БД можно дополнять  таблицу новыми полями. Созданную  таблицу необходимо сохранить, дав  ей имя, уникальное в пределах создаваемой  базы.

При проектировании таблиц, рекомендуется руководствоваться  следующими основными принципами:

1. Информация в таблице не должна дублироваться. Не должно быть повторений и между таблицами. Когда определенная информация храниться только в одной таблице,  то и  изменять её придется только в одном месте. Это делает работу более эффективной, а также исключает возможность несовпадения информации в разных таблицах. Например, в одной таблице должны содержаться адреса и телефоны клиентов.
2. Каждая таблица должна содержать информацию только на одну тему. Сведения на каждую тему обрабатываются намного легче, если они содержаться в независимых друг от друга таблицах. Например, адреса и заказы клиентов лучше хранить в разных таблицах, с тем, чтобы при удалении заказа информация о клиенте осталась в базе данных.
3. Каждая таблица должна содержать необходимые поля. Каждое поле в таблице должно содержать отдельные сведения по теме таблицы. Например, в таблице с данными о клиенте могут содержаться поля с названием компании, адресом, городом, страной и номером телефона. При разработке полей для каждой таблицы необходимая информация. Необходимо помнить, что каждое поле должно быть связано с темой таблицы. Не рекомендуется включать в таблицу данные, которые являются результатом выражения. В таблице должна присутствовать вся необходимая информация. Информацию следует разбивать на наименьшие логические единицы (Например, поля «Имя» и «Фамилия», а не общее поле «Имя»).
4. База данных должна иметь первичный ключ. Это необходимо для того, чтобы СУБД могла связать данные из разных таблиц, например данные о клиенте и его заказы.

Стадия 3. Создание экранных форм.

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

Стадия 4. Заполнение БД.

Процесс заполнения БД может  производиться в двух видах: в  виде таблицы и в виде формы. Числовые и текстовые поля можно заполнять  в виде таблицы, а поля типа MEMO и OLE – в виде формы.

6. Работа с созданной базой данных.

Работа с БД включает в  себя следующие действия:

• поиск необходимых сведений;
• сортировка данных;
• отбор данных;
• вывод на печать;
• изменение и дополнение данных.

Виды проектирования.

Концептуальное (инфологическое) проектирование – построение семантической модели предметной области, то есть информационной модели наиболее высокого уровня абстракции. Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных. Термины «семантическая модель», «концептуальная модель» и «инфологическая модель» являются синонимами. Кроме того, в этом контексте равноправно могут использоваться слова «модель базы данных» и «модель предметной области» (например, «концептуальная модель базы данных» и «концептуальная модель предметной области»), поскольку такая модель является как образом реальности, так и образом проектируемой базы данных для этой реальности. Конкретный вид и содержание концептуальной модели базы данных определяется выбранным для этого формальным аппаратом. Обычно используются графические нотации, подобные ER-диаграммам.

Чаще всего концептуальная модель базы данных включает в себя:

• описание информационных объектов, или понятий предметной области и связей между ними;
• описание ограничений целостности, т.е. требований к допустимым значениям данных и к связям между ними.

Логическое (даталогическое) проектирование – создание схемы базы данных на основе конкретной модели данных, например, реляционной модели данных. Для реляционной модели данных даталогическая модель – набор схем отношений, обычно с указанием первичных ключей, а также «связей» между отношениями, представляющих собой внешние ключи.

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

Физическое проектирование – создание схемы базы данных для конкретной СУБД. Специфика конкретной СУБД может включать в себя ограничения на именование объектов базы данных, ограничения на поддерживаемые типы данных и т.п. Кроме того, специфика конкретной СУБД при физическом проектировании включает выбор решений, связанных с физической средой хранения данных (выбор методов управления дисковой памятью, разделение БД по файлам и устройствам, методов доступа к данным), создание индексов и т.д.

Физическая организация  БД.

Наиболее часто таблица  с отношением размещается в отдельном  файле. В некоторых СУБД одна отдельная  таблица (отношение) считается базой  данных. В других СУБД база данных может содержать несколько таблиц. В общем случае можно считать, что БД включает одну или несколько таблиц, объединенных смысловым содержанием, а также процедурами контроля целостности и обработки информации в интересах решения некоторой прикладной задачи. Например, при использовании СУБД Microsoft Access в файле БД наряду с таблицами хранятся и другие объекты базы: запросы, отчеты, формы, макросы и модули. Имена полей хранятся внутри словаря базы данных. Правила их формирования определяются СУБД, которые, как правило, на длину полей и используемый алфавит серьезных ограничений не накладывают.

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Список использованной литературы.

1. http://ru.wikipedia.org/wiki/База_данных
2. http://ru.wikipedia.org/wiki/Проектирование_баз_данных
3. http://inf.e-alekseev.ru/text/Etapy_bd.html
4. http://archae-dev.com/l3r5part1.htm
5. http://www.slideshare.net/lavrov/ss-4659919