среда, 19 марта 2014 г.

Создание форм


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


  • Обычно в форму переносятся все поля таблицы, на основе которой построена форма. Дополнительно форма может содержать списки выбора, текстовые поля, графические объекты.
  • Продолжаем создавать БД Расписание.

Практическая работа 2. Создание и редактирование форм БД Расписание

среда, 5 марта 2014 г.

Разработка реляционной БД Расписание

I этап. Постановка задачи

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



II этап. Проектирование БД «Расписание»

В рассматриваемой предметной области выделяем следующие классы объектов: дни недели, уроки, классы, предметы, преподаватели, расписание уроков 

Каждый класс объектов выделяем в отдельную таблицу.

При построении каждой таблицы вводим суррогатный ключ

БД должна содержать таблицы:
  • Таблица ДниНедели – перечень всех дней недели. (Первичный ключ – IDДняНедели)
  • Таблица Уроки – сведения о начале, завершении уроков с 1 по 7. (Первичный ключ – IDУрока)
  • Таблица Классы – сведения о классах школы. (Первичный ключ – IDКласса)
  • Таблица Предметы – сведения о преподаваемых дисциплинах. (Первичный ключ – IDПредмета)
  • Таблица Преподаватели – сведения о преподавателях школы. (Первичный ключ – IDПреподавателя)
  • Таблица Расписание – показывает на каком уроке, для какого класса, какой предмет преподает конкретный преподаватель. (Первичный ключ –  IDРасписания)
БД должна содержать по одной форме для каждой таблицы (требования будут изложены позднее)

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

БД будет иметь реляционную структуру и работать под управлением СУБД LibreOffice Base.
Практическая работа 1. Создание таблиц БД Расписание

суббота, 1 марта 2014 г.

СУБД. Реляционные Базы Данных. Нормализация БД


Смотрим презентацию К.Ю.Полякова (слайды 37 - 45)
В середине ХХ века при проектировании и эксплуатации разработанных БД возникли следующие задачи:
  • Разработать строгое математическое описание баз данных, независимое от способа хранения данных;
  • Разработать методы управления этими данными
В 1970 г Эдгар Кодд, который работал в фирме IBM, предложил новую модель данных , основанную на следующих идеях:
  • Все данные представляют свойства некоторых объектов;
  • Объекты делятся на классы;
  • Данные о некотором объекте — это набор свойств (атрибутов). Каждое свойство задается парой «название — значение».
Математическая теория Кодда никак не связана с тем, как хранятся данные. Однако на основании теории Кодда легко строить табличные БД.
Действительно:
  • Каждая таблица описывает один класс объектов;
  • Порядок расположения полей в таблице не имеет значения;
  • Все значения одного поля относятся к одному типу данных;
  • В таблице нет двух одинаковых записей;
  • Порядок записей в таблице не определен

Поэтому можно дать следующее определение:

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

  1. Любое поле должно быть неделимым 
  2. Любое неключевое поле должно зависеть от ключа таблицы. Если в таблице есть поле, которое не зависит от ключа этой таблицы, значит, это поле описывает другой класс объектов. Это поле нужно вынести в другую таблицу. А между таблицами установить связь. 
  3. Не должно быть одинаковых по смыслу полей. 
  4. Не нужно хранить данные, которые могут быть вычислены.

На практике эти принципы можно преобразовать в план
  1. Для каждого класса объектов создавать отдельную таблицу.
  2. При построении каждой таблицы вводим суррогатный ключ. Для всех суррогатных ключей выбираем тип INTEGER 
  3. Для каждой таблицы определяем типы данных каждого поля
  4. Связываем таблицы связями 1:N. Не забудьте! Связи устанавливаются между однотипными полями. 
В результате нормализации  получаем  схему БД, состоящую из нескольких таблиц