Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Ответы на вопросы дополнено.docx
Скачиваний:
6
Добавлен:
19.09.2019
Размер:
1.4 Mб
Скачать

Базы данных

  1. Этапы проектирования базы данных. Требования к СУБД.

Этапы:

1. Определение цели создания базы данных.

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

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

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

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

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

Каждая таблица содержит информацию на отдельную тему, а каждое поле в таблице содержит отдельные сведения по теме таблицы.

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

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

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

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

Если структуры таблиц отвечают поставленным требованиям, то можно вводить все данные. Затем можно создавать любые запросы, формы, отчеты, макросы и модули.

Требования к СУБД.

Безопасное хранение данных, подразумевающее защиту как от сбоев и погрешностей оператора, так и от несанкционированного доступа и переноса.

Возожности поиска, сортировки и отбора данных по заданным пользователем признакам.

Возможность «неквалифицированного» ввода информации в базу персоналом с минимальной компьютерной подготовкой.

Оформление и выдача печатных материалов, желательно с прямым подключением драйверов принтера для ускорения процесса печати.

При необходимости – конвертация данных из других форматов и прием информации в базу.

  1. Классификация СУБД..

По модели данных

Примеры:

  • Иерархические

    • Иерархические СУБД - поддерживают древовидную организацию информации. Связи между записями выражаются в виде отношений предок/потомок, а у каждой записи есть ровно одна родительская запись. Это помогает поддерживать ссылочную целостность. Когда запись удаляется из дерева, все ее потомки также должны быть удалены. 

  • Сетевые

    • Сетевая модель расширяет иерархическую модель СУБД, позволяя группировать связи между записями в множества. С логической точки зрения связь — это не сама запись. Связи лишь выражают отношения между записями. Как и в иерархической модели, связи ведут от родительской записи к дочерней, но на этот раз поддерживается множественное наследование.

  • Реляционные

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

  • Объектно-ориентированные

    • Объектно-ориентированная (объектная) СУБД — система управления базами данных, основанная на объектной модели данных. Эта система управления обрабатывает данные как абстрактные объекты, наделённые свойствами, в виде неструктурированных данных, и использующие методы взаимодействия с другими объектами окружающего мира.

  • Объектно-реляционные

    • Объектно-реляционная СУБД (ОРСУБД) — реляционная СУБД (РСУБД), поддерживающая некоторые технологии, реализующие объектно-ориентированный подход.

Объектно-реляционными СУБД являются, к примеру, широко известные Oracle Database, Informix, DB2, PostgreSQL, FirstSQL/J.

По степени распределённости

  • Локальные СУБД (все части локальной СУБД размещаются на одном компьютере)

  • Распределённые СУБД (части СУБД могут размещаться на двух и более компьютерах).