Фон

Я студент першого курсу, і працюю неповний робочий день для малого бізнесу тата. Я не маю досвіду в розробці додатків у реальному світі. Я написав сценарії в Python, деякі курсові роботи на C, але нічого подібного.

У мого тата є невеликий навчальний бізнес, і зараз усі заняття заплановані, записуються та проводяться через зовнішню веб-програму. Існує функція експорту / "звітів", але вона є загальною, і нам потрібні конкретні звіти. У нас немає доступу до фактичної бази даних для запуску запитів. Мене попросили створити власну систему звітності.

Моя ідея - створити загальний CSV-експорт та імпорт (можливо, з Python) їх у базу даних MySQL, що розміщується в офісі щовечора, звідки я можу запускати конкретні запити, які потрібні. Я не маю досвіду роботи з базами даних, але розумію основи. Я трохи прочитав про створення бази даних та звичайні форми.

Ми можемо незабаром почати мати міжнародних клієнтів, тому я хочу, щоб база даних не вибухнула, якщо / коли це станеться. Наразі у нас є кілька великих корпорацій як клієнтів, що мають різні підрозділи (наприклад, материнська компанія ACME, відділ охорони здоров'я ACME, відділ догляду за тілом ACME)

Схема, яку я придумала, така:

1. З точки зору клієнта:
   • Клієнти - це основна таблиця
   • Клієнти пов'язані з відділом, в якому працюють
     • Департаменти можуть бути розкидані по країні: HR в Лондоні, Маркетинг у Свонсі тощо.
     • Департаменти пов'язані з підрозділом компанії
   • Підрозділи пов'язані з материнською компанією
2. З точки зору занять:
   • Сесії - це основна таблиця
     • Викладач пов'язаний з кожним заняттям
     • Кожному сеансу надається statusid. Наприклад 0 - завершено, 1 - скасовано
     • Сесії групуються в "пакети" довільної величини
   • Кожен пакет призначається клієнту

Я «сконструював» (більше схожий на накреслений) схему на аркуші паперу, намагаючись тримати її нормалізованою до 3-го класу. Потім я підключив його до MySQL Workbench, і це зробило все для мене гарним:
( Клацніть тут для повнорозмірної графіки )

_{(джерело: maian.org )}

Приклад запитів я буду виконувати

• Клієнти з кредитом все ще залишаються неактивними (ті, хто не має запланованого класу в майбутньому)
• Який показник відвідуваності кожного клієнта / відділу / підрозділу (вимірюється ідентифікатором статусу в кожному сеансі)
• Скільки класів мав учитель за місяць
• Прапорці клієнтів, які мають низьку відвідуваність
• Спеціальні звіти для відділів кадрів із відвідуванням відвідувачів підрозділів

Питання (и)

• Це переосмислене чи я рухаюся правильним шляхом?
• Чи призведе до необхідності приєднання декількох таблиць для більшості запитів до великого успіху?
• Я додав стовпчик "lastsession", оскільки це, ймовірно, буде загальним запитом. Це гарна ідея чи я повинен тримати базу даних суворо нормалізованою?

Дякую за ваш час

Ще кілька відповідей на ваші запитання:

1) Ви в значній мірі націлені на того, хто вперше підходить до такої проблеми. Я думаю, що покажчики інших питань на це питання поки що в значній мірі висвітлюють це. Хороша робота!

2 та 3) Показник ефективності, який ви будете приймати, значною мірою залежатиме від наявності та оптимізації правильних індексів для ваших конкретних запитів / процедур та, що важливіше, від обсягу записів. Якщо ви не говорите про більш ніж мільйон записів у своїх основних таблицях, ви, здається, стежите за тим, щоб мати достатньо основний дизайн, що продуктивність не буде проблемою для розумного обладнання.

Це було сказано, і це стосується вашого питання 3, з початку ви, мабуть, не повинні надто хвилюватися з приводу ефективності або гіперчутливості до нормалізації православ'я тут. Це сервер звітування, який ви будуєте, а не бекенд програми, заснованого на транзакціях, який матиме набагато інший профіль щодо важливості продуктивності чи нормалізації. База даних, що підтримує додаток для реєстрації в режимі реального часу та планування, має пам’ятати про запити, які потребують секунд, щоб повернути дані. Функція сервера звітів має не лише більшу толерантність до складних та тривалих запитів, але й стратегії підвищення продуктивності значно відрізняються.

Наприклад, в середовищі додатків на основі транзакцій ваші варіанти підвищення продуктивності можуть включати рефакторинг збережених процедур та структур таблиць до n-го ступеня або розробку стратегії кешування невеликих кількостей часто запитуваних даних. У звітному середовищі ви, безумовно, можете це зробити, але ви можете зробити ще більший вплив на продуктивність, запровадивши механізм знімків, коли запускається запланований процес і зберігає заздалегідь налаштовані звіти, а ваші користувачі отримують доступ до даних знімків, не напружуючи рівень вашого db. на основі запиту.

Все це - довга думка про те, щоб проілюструвати, що принципи дизайну та хитрощі, які ви використовуєте, можуть відрізнятися, враховуючи роль створюваного db. Я сподіваюся, що це корисно.

Ви отримали правильну ідею. Однак ви можете очистити його та видалити деякі таблиці зіставлення (має *).

Що можна зробити - це у таблиці Департаменти, додати CityId та DivisionId.

Крім того, я думаю, що все добре ...

Єдині зміни, які я б вніс, - це:
1. Змініть свій VARCHAR на NVARCHAR; якщо ви, можливо, будете міжнародними, вам може знадобитися unicode.

2- Змініть свій ідентичний код на GUID (унікальний ідентифікатор), якщо це можливо (це може бути моїм особистим уподобанням). Якщо припустити, що ви зрештою дістанетесь до того, що у вас є декілька середовищ (dev / test / staging / prod), можливо, ви захочете перенести дані з одного в інший. Має ідентифікатори GUID значно полегшує це.

3- Три шари для вашої компанії -> Відділ -> Структура відділу може бути недостатньою. Тепер це може бути надмірно інженерним, але ви можете узагальнити таку ієрархію таким чином, щоб ви могли підтримувати n-рівні глибини. Це зробить деякі ваші запити складнішими, так що, можливо, це не варто. Крім того, може бути, що будь-який клієнт, який має більше шарів, може бути легко "заправним" у цій моделі.

4- У вас також є статус у таблиці клієнтів, який є VARCHAR і не має посилання на таблицю статусів. Я очікую трохи більше ясності щодо того, що являє собою статус клієнта.

Ні. Схоже, ви проектуєте з хорошим рівнем деталізації.

Я думаю, що країни та компанії - це та сама сутність у вашому дизайні, як і міста та відділи. Я позбудусь таблиць країн і міст (і міст_Has_Departments) і, якщо потрібно, додамо бульовий прапор IsPublicSector до таблиці компаній (або стовпчик CompanyType, якщо більше варіантів, ніж просто приватний сектор / громадський сектор).

Крім того, я думаю, що у використанні таблиці відділів є помилка. Схоже, таблиця відділів служить посиланням на різні види відділів, які може мати кожен відділ клієнтів. Якщо це так, його слід називати DepartmentTypes. Але ваші клієнти (які, я припускаю, відвідувачі) не належать до відділу TYPE, вони належать до фактичного примірника відділу в компанії. Наразі ви знаєте, що даний клієнт десь належить до відділу кадрів, а не до якого!

Іншими словами, Клієнтів слід пов’язати з таблицею, яку ви називаєте Відділи_Хас_Департаменти (але яку я назвав би просто Департаменти). Якщо це так, то ви повинні розбити міста на підрозділи, як обговорювалося вище, якщо ви хочете використовувати стандартну референтну цілісність у базі даних.

До речі, варто зауважити, що якщо ви вже генеруєте CSV-файли і хочете завантажити їх у базу даних mySQL, LOAD DATA LOCAL INFILE - ваш найкращий друг: http://dev.mysql.com/doc/refman/5.1/ uk / load-data.html . Mysqlimport також варто вивчити, і це інструмент командного рядка, який в основному є гарною обгорткою навколо завантаження даних про завантаження.

Більшість речей вже було сказано, але я вважаю, що можу додати одне: молодші розробники нерідко переживають за ефективність трохи заздалегідь, і ваше питання щодо приєднання до таблиць, схоже, йде в цьому напрямку. Це анти-модель розробки програмного забезпечення під назвою " Передчасна оптимізація ". Спробуйте вигнати цей розум з розуму :)

І ще одне: чи вірите ви, що вам справді потрібні таблиці "міст" та "країн"? Чи не матиме стовпці "місто" та "країна" у таблиці відділів, чи достатньо для ваших випадків використання? Наприклад, чи потрібно вашій заяві перераховувати відділи за містами та містами по країнах?

Наступні коментарі на основі ролі спеціаліста з бізнес-аналітики / звітності та менеджера стратегії / планування:

1. Я згоден з вищевказаним напрямком Ларрі. ІМХО, це не так вже й багато, що спроектовано, деякі речі виглядають трохи поза місцем. Щоб зробити це просто, я б позначив клієнта безпосередньо на ідентифікатор компанії, опис відділу, опис відділу, ідентифікатор типу відділу, ідентифікатор типу підрозділу. Використовуйте ідентифікатор типу відділу та ідентифікатор типу підрозділу як посилання на таблиці пошуку та внутрішні поля звітування / аналізу для довгострокової послідовності.

2. Таблиця пакетів містить стовпчик "Кредит", чи не слід насправді прив'язувати до базової таблиці Клієнта, тому якщо у них багато пакетів, ви можете побачити, скільки кредиту заборгованості залишилось для майбутніх класів? Додаток може піклуватися про вирахування та зберігати його центрально в таблиці Клієнта.

3. Інформація про компанію може використовувати багато інших полів, включаючи очевидну адресу / телефон / тощо. інформація. Я також буду готовий додати в колонки D&B "DUNs" (Сайт / відділення / Ultimate) довгостроковий термін, Dun and Bradstreet (D&B) має величезний каталог компаній, і ви дізнаєтесь згодом у дорозі, їх інформація дуже корисна. для звітування / аналізу. Це допоможе вирішити проблему з декількома поділами, яку ви згадуєте, і дозволить згорнути їх ієрархію для підрозділів / відділень / гілок / тощо. великого корпусу.

4. Ви не згадуєте, з якою кількістю записів ви будете працювати, що може означати налаштування себе на велику ініціативу розвитку, яка могла б зробити швидше і набагато менше головних болів із заздалегідь встановленим програмним забезпеченням для "звітування". Якщо ви не маєте великої кількості баз даних (<65000), переконайтесь, що MS-Access, OpenOffice (Base) або пов'язані з ними рішення для розробників звітів / додатків не змогли зробити цього. Я безкоштовно використовую безкоштовне програмне забезпечення APEX від Oracle, він постачається з їх безкоштовною базою даних Oracle XE, просто завантажуючи його з свого сайту.

5. FYI - Звіт про звіт: для великих баз даних, як правило, є два екземпляри бази даних: a) База даних транзакцій для запису кожного детального запису. б) база даних звітів (март даних / сховище даних), розміщена на окремій машині. Для отримання додаткової інформації шукайте google і зіркову схему, і схему Сніжинки.

З повагою

Я хочу вирішити лише стурбованість тим, що приєднання до безглуздих таблиць спричинить хіт ефективності. Не бійтеся нормалізуватися, тому що вам доведеться робити приєднання. Приєднання нормальні і очікувані в реляційних датах, і вони розроблені для того, щоб добре їх обробляти. Вам потрібно буде встановити відносини PK / FK (для цілісності даних це важливо враховувати при розробці), але у багатьох базах даних FK не індексуються автоматично. Оскільки вони будуть використовуватися при з'єднанні, ви, безумовно, хочете почати з індексації FKS. ПК зазвичай отримують індекс про створення, оскільки вони повинні бути унікальними. Це правда, що дизайн сховища даних зменшує кількість приєднань, але, як правило, не доводиться зберігати дані, доки в одному звіті не буде мільйонів записів. Навіть тоді майже всі сховища даних починають використовувати транзакційну базу даних для збору даних у режимі реального часу, а потім дані переміщуються на склад за графіком (щоночі або щомісяця або все, що потрібно бізнесу). Тож це хороший початок, навіть якщо вам потрібно пізніше розробити сховище даних для підвищення продуктивності звіту.

Треба сказати, що ваш дизайн вражає студентів першого курсу.

Це не надто інженерно, саме так я б підійшов до проблеми. Приєднання нормально, не буде великого показника ефективності (це абсолютно необхідно, якщо ви не денормалізуєте базу даних, що не рекомендується!). Щодо статусів, дивіться, чи можете ви замість цього використовувати тип даних enum для оптимізації цієї таблиці.

Я працював у навчальній / шкільній області, і я вважав, що хочу зазначити, що взагалі існує зв'язок M: 1 між тим, що ви називаєте "сеансами" (екземплярами заданого курсу), і самим курсом. Іншими словами, у вашому каталозі пропонується курс ("іспанська 101" чи будь-який інший), але у вас можуть бути два різних екземпляри його протягом одного семестру (Tu-Th викладає Сміт, Ср-Пт викладає Джонс).

Крім цього, це виглядає як вдалий старт. Б'юсь об заклад, ви виявите, що домен клієнта (графіки, що ведуть до "клієнтів") складніший, ніж ви моделювали, але не перестарайтеся з цим, поки у вас не з’являться реальні дані, які б вас орієнтували.

Кілька речей прийшли до тями:

1. Столи, здавалося, орієнтовані на звітність, але насправді не ведуть бізнес. Я думаю, коли клієнт підписується, по суті, робиться замовлення для клієнта, який відвідує список сесій, і це замовлення може бути для декількох працівників в одній компанії. Здавалося б, таблиця "замовлення" дійсно опиниться в центрі вашої системи, яка сприятиме захопленню даних та можливій звітності. (Порівняйте паперові документи, які ви використовували для ведення бізнесу, з дизайном вашої бази даних, щоб побачити, чи є логічна відповідність.)

2. Компанії часто не мають підрозділів. Співробітники іноді змінюють підрозділи / відділи, можливо навіть на середині сесії. Компанії іноді додають / видаляють / перейменують підрозділи / відділи. Переконайтесь, що можливий зміст вмісту ваших таблиць у режимі реального часу не ускладнює подальше звітування / групування. Оскільки стільки контактних даних розділено на стільки таблиць, вам, можливо, доведеться застосувати дуже сувору перевірку введення даних, щоб зберегти ваші звіти значимими та всеосяжними. Наприклад, коли додається новий клієнт, переконуючись, що його компанія / відділ / відділ / місто відповідають тим же значенням, що і його колеги.

3. Концепція "пачки" зовсім не зрозуміла.

4. Оскільки ви вказуєте, що це малий бізнес, було б дивно, якщо продуктивність буде проблемою, враховуючи швидкість та потужність сучасних машин.