Mysql
 sql >> база данни >  >> RDS >> Mysql

Ръководство за проектиране на база данни за система за управление на служители в MySQL

Този урок предоставя пълните стъпки за проектиране на схема на база данни на системата за управление на служители за управление на потребителите, ролите, разрешенията, организациите и служителите.

Диаграмата на взаимоотношенията на обектите или визуалният дизайн на базата данни е показан по-долу.

База данни за управление на служители

Можете също да посетите популярните уроци, включително Как да инсталирате MySQL 8 на Ubuntu 20.04 LTS, Как да инсталирате MySQL 8 на Windows, Как да инсталирате MySQL Workbench на Ubuntu, Как да инсталирате MySQL 8 с Workbench на Windows 10, RBAC база данни в MySql, База данни за блогове в MySql, База данни за тестове в MySQL, База данни за анкети и анкети в MySQL, База данни за онлайн пазарска кошница в MySQL, База данни за инвентаризация в MySQL и Научете основни SQL заявки в MySQL.

Бележки :Можете също така да следвате персонализираната схема на база данни на системата за управление на служителите, за да получите персонализирани решения въз основа на вашите изисквания.

Организационна база данни

Първата стъпка е да създадете Организационна база данни. Може да се създаде с помощта на заявката, както е показано по-долу.

CREATE SCHEMA `organization` DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

Използвал съм набора от знаци utf8mb4 за поддръжка на широк спектър от знаци.

Таблица с роли

В този раздел ще проектираме Таблица с роли за съхраняване на ролите на системата и организацията. Типът колона може да се използва за идентифициране дали ролята е за потребителите на приложението или служителите на организацията. По-долу е споменато описанието на всички колони на таблицата с роли.

Id Уникалният идентификатор за идентифициране на ролята.
Заглавие Заглавието на ролята.
Плюс Уникалният плуг за търсене на ролята.
Описание Описанието за споменаване на ролята.
Тип Типът роля за разграничаване между системни и организационни роли.
Активно Флагът за проверка дали ролята е активна в момента.
Създаден в Той съхранява датата и часа, в които е създадена ролята.
Актуализирано в Той съхранява датата и часа, в които ролята се актуализира.
Съдържание Пълните подробности за ролята.

Таблицата на ролите със съответните ограничения е както е показано по-долу.

CREATE TABLE `organization`.`role` (
`id` BIGINT NOT NULL AUTO_INCREMENT,
`title` VARCHAR(75) NOT NULL,
`slug` VARCHAR(100) NOT NULL,
`description` TINYTEXT NULL,
`type` SMALLINT NOT NULL DEFAULT 0,
`active` TINYINT NOT NULL DEFAULT 0,
`createdAt` DATETIME NOT NULL,
`updatedAt` DATETIME NULL DEFAULT NULL,
`content` TEXT NULL DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE INDEX `uq_slug` (`slug` ASC) );

Таблица с разрешения

В този раздел ще проектираме Таблица с разрешения за съхраняване на разрешенията за системата и организацията. Типът колона може да се използва за идентифициране дали разрешението е за потребителите на приложението или служителите на организацията. По-долу е посочено описанието на всички колони на таблицата с разрешения.

Id Уникалният идентификатор за идентифициране на разрешението.
Заглавие Заглавието на разрешението.
Плюс Уникалният плуг за търсене в разрешението.
Описание Описанието за споменаване на разрешението.
Тип Типът на разрешение за разграничаване между системни и организационни разрешения.
Активно Флагът за проверка дали разрешението е активно в момента.
Създаден в Той съхранява датата и часа, на които е създадено разрешението.
Актуализирано в Той съхранява датата и часа, в които разрешението е актуализирано.
Съдържание Пълните подробности за разрешението.

Таблицата с разрешения със съответните ограничения е както е показано по-долу.

CREATE TABLE `organization`.`permission` (
`id` BIGINT NOT NULL AUTO_INCREMENT,
`title` VARCHAR(75) NOT NULL,
`slug` VARCHAR(100) NOT NULL,
`description` TINYTEXT NULL,
`type` SMALLINT NOT NULL DEFAULT 0,
`active` TINYINT NOT NULL DEFAULT 0,
`createdAt` DATETIME NOT NULL,
`updatedAt` DATETIME NULL DEFAULT NULL,
`content` TEXT NULL DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE INDEX `uq_slug` (`slug` ASC) );

Таблица с разрешения за роли

Таблица с разрешения за роли може да се използва за съхраняване на съпоставянията на разрешенията към ролите. По-долу е посочено описанието на всички колони в таблицата с разрешения за роли.

Идентификатор на ролята Идентификаторът на ролята за идентифициране на ролята.
Идентификатор на разрешение Идентификаторът на разрешението за идентифициране на разрешението.
Създаден в Той съхранява датата и часа, в които е създадено картографирането.
Актуализирано в Той съхранява датата и часа, в които картографирането се актуализира.

Таблицата с разрешения за роли със съответните ограничения е както е показано по-долу.

CREATE TABLE `organization`.`role_permission` (
`roleId` BIGINT NOT NULL,
`permissionId` BIGINT NOT NULL,
`createdAt` DATETIME NOT NULL,
`updatedAt` DATETIME NULL,
PRIMARY KEY (`roleId`, `permissionId`),
INDEX `idx_rp_role` (`roleId` ASC),
INDEX `idx_rp_permission` (`permissionId` ASC),
CONSTRAINT `fk_rp_role`
FOREIGN KEY (`roleId`)
REFERENCES `organization`.`role` (`id`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_rp_permission`
FOREIGN KEY (`permissionId`)
REFERENCES `organization`.`permission` (`id`)
ON DELETE NO ACTION
ON UPDATE NO ACTION);

Таблица с потребители

В този раздел ще проектираме Таблица на потребителите за съхраняване на потребителска информация. Потребителите могат да управляват собствените си профили. Също така, потребителите могат да използват приложението според назначените им системни роли. По-долу е посочено описанието на всички колони на потребителската таблица.

Id Уникалният идентификатор за идентифициране на потребителя.
Идентификатор на ролята Ролята на потребителя. Може да бъде администратор или потребител.
Име Първото име на потребителя.
Биринно име Биринното име на потребителя.
Фамилия Фамилията на потребителя.
Мобилни Мобилният номер на потребителя. Може да се използва за влизане и регистрация.
Имейл Имейлът на потребителя. Може да се използва за влизане и регистрация.
Хеш на парола Хешът на паролата, генериран от подходящия алгоритъм. Трябва да избягваме съхраняването на обикновени или криптирани пароли.
Регистриран в Тази колона може да се използва за изчисляване на живота на потребителя с приложението.
Последно влизане Може да се използва за идентифициране на последното влизане на потребителя.
Въведение Краткото представяне на потребителя.
Профил Подробности за потребителя.

Потребителската таблица със съответните ограничения е показана по-долу.

CREATE TABLE `organization`.`user` (
`id` BIGINT NOT NULL AUTO_INCREMENT,
`roleId` BIGINT NOT NULL,
`firstName` VARCHAR(50) NULL DEFAULT NULL,
`middleName` VARCHAR(50) NULL DEFAULT NULL,
`lastName` VARCHAR(50) NULL DEFAULT NULL,
`username` VARCHAR(50) NULL DEFAULT NULL,
`mobile` VARCHAR(15) NULL,
`email` VARCHAR(50) NULL,
`passwordHash` VARCHAR(32) NOT NULL,
`registeredAt` DATETIME NOT NULL,
`lastLogin` DATETIME NULL DEFAULT NULL,
`intro` TINYTEXT NULL DEFAULT NULL,
`profile` TEXT NULL DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE INDEX `uq_username` (`username` ASC),
UNIQUE INDEX `uq_mobile` (`mobile` ASC),
UNIQUE INDEX `uq_email` (`email` ASC),
INDEX `idx_user_role` (`roleId` ASC),
CONSTRAINT `fk_user_role`
FOREIGN KEY (`roleId`)
REFERENCES `organization`.`role` (`id`)
ON DELETE NO ACTION
ON UPDATE NO ACTION);

Организационна таблица

В този раздел ще проектираме организационната таблица за съхраняване на данните за организацията. По-долу е посочено описанието на всички колони на организационната таблица.

Id Уникалният идентификатор за идентифициране на организацията.
Създадено от Идентификацията на потребителя за идентифициране на потребителя, който е регистрирал организацията.
Актуализирано от Идентификацията на потребителя за идентифициране на потребителя, който е актуализирал организацията.
Заглавие Заглавието на организацията.
Метазаглавие Мета заглавието, което ще се използва за заглавие на браузъра и SEO цели.
Плюс Плужката за образуване на уникалния URL адрес.
Резюме Резюме за споменаване на ключови акценти.
Състояние Състоянието на организацията може да бъде Нова, Одобрена, Активна или Блокирана.
Създаден в Той съхранява датата и часа, в които организацията е създадена.
Актуализирано в Той съхранява датата и часа, в които организацията се актуализира.
Профил Колоната, използвана за съхраняване на данните за профила на организацията.
Съдържание Колоната, използвана за съхраняване на допълнителни подробности за организацията.

Той използва състоянието на колоната за проследяване на състоянието на организацията. Състоянието може да бъде Нов, Одобрен, Активен или Блокиран. Организационната таблица със съответните ограничения е както е показано по-долу.

CREATE TABLE `organization`.`organization` (
`id` BIGINT NOT NULL AUTO_INCREMENT,
`createdBy` BIGINT NOT NULL,
`updatedBy` BIGINT NOT NULL,
`title` VARCHAR(75) NOT NULL,
`metaTitle` VARCHAR(100) NULL,
`slug` VARCHAR(100) NOT NULL,
`summary` TINYTEXT NULL,
`status` SMALLINT NOT NULL DEFAULT 0,
`createdAt` DATETIME NOT NULL,
`updatedAt` DATETIME NULL DEFAULT NULL,
`profile` TEXT NULL DEFAULT NULL,
`content` TEXT NULL DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE INDEX `uq_slug` (`slug` ASC),
INDEX `idx_organization_creator` (`createdBy` ASC),
CONSTRAINT `fk_organization_creator`
FOREIGN KEY (`createdBy`)
REFERENCES `organization`.`user` (`id`)
ON DELETE NO ACTION
ON UPDATE NO ACTION);

ALTER TABLE `organization`.`organization`
ADD INDEX `idx_organization_modifier` (`updatedBy` ASC);
ALTER TABLE `organization`.`organization`
ADD CONSTRAINT `fk_organization_modifier`
FOREIGN KEY (`updatedBy`)
REFERENCES `organization`.`user` (`id`)
ON DELETE NO ACTION
ON UPDATE NO ACTION;

Мета на организация

Организационната метатаблица може да се използва за съхраняване на допълнителна информация за организации, включително URL адреса на банера на организацията и т.н. По-долу е посочено описанието на всички колони на метатаблицата на организацията.

Id Уникалният идентификатор за идентифициране на мета на организацията.
Идентификатор на организация Идентификаторът на организацията за идентифициране на родителската организация.
Ключ Ключът, идентифициращ мета.
Съдържание Колоната, използвана за съхраняване на метаданните на организацията.

Организационната метатаблица със съответните ограничения е както е показано по-долу.

CREATE TABLE `organization`.`organization_meta` (
`id` BIGINT NOT NULL AUTO_INCREMENT,
`organizationId` BIGINT NOT NULL,
`key` VARCHAR(50) NOT NULL,
`content` TEXT NULL DEFAULT NULL,
PRIMARY KEY (`id`),
INDEX `idx_meta_organization` (`organizationId` ASC),
UNIQUE INDEX `uq_meta_organization` (`organizationId` ASC, `key` ASC),
CONSTRAINT `fk_meta_organization`
FOREIGN KEY (`organizationId`)
REFERENCES `organization`.`organization` (`id`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;

Таблица на служителите

В този раздел ще проектираме Таблица на служителите за съхраняване на данните за служителите. По-долу е посочено описанието на всички колони на таблицата на служителите.

Id Уникалният идентификатор за идентифициране на служителя.
Потребителски идентификатор Потребителският идентификатор за идентифициране на потребителя, свързан със Служителя.
Идентификатор на ролята Идентификаторът на ролята, специфичен за организацията, присвоен на служителя.
Създадено от Идентификаторът на потребителя за идентифициране на потребителя, добавил служителя.
Актуализирано от Потребителският идентификатор за идентифициране на потребителя, който е актуализирал служителя.
Код Кодът, използван от организацията за идентифициране на служителя.
Състояние Състоянието на служителя може да бъде Нов, Одобрен, Активен, Блокиран или Прекратен.
Създаден в Той съхранява датата и часа, в които служителят е създаден.
Актуализирано в Той съхранява датата и часа, в които служителят е актуализиран.
Започва в Той съхранява датата и часа, в които започва работа.
Завършва в Той съхранява датата и часа, в които заетостта приключва.
Бележки Колоната, използвана за съхраняване на бележките, специфични за работата.

Той използва състоянието на колоната за проследяване на състоянието на служителя. Състоянието може да бъде Нов, Одобрен, Активен, Блокиран или Прекратен. Таблицата на служителите със съответните ограничения е както е показано по-долу.

CREATE TABLE `organization`.`employee` (
`id` BIGINT NOT NULL AUTO_INCREMENT,
`organizationId` BIGINT NOT NULL,
`userId` BIGINT NOT NULL,
`roleId` BIGINT NOT NULL,
`createdBy` BIGINT NOT NULL,
`updatedBy` BIGINT NOT NULL,
`code` VARCHAR(100) NOT NULL,
`status` SMALLINT NOT NULL DEFAULT 0,
`createdAt` DATETIME NOT NULL,
`updatedAt` DATETIME NULL DEFAULT NULL,
`startsAt` DATETIME NULL DEFAULT NULL,
`endsAt` DATETIME NULL DEFAULT NULL,
`notes` TEXT NULL DEFAULT NULL,
PRIMARY KEY (`id`),
INDEX `idx_employee_user` (`userId` ASC),
CONSTRAINT `fk_employee_user`
FOREIGN KEY (`userId`)
REFERENCES `organization`.`user` (`id`)
ON DELETE NO ACTION
ON UPDATE NO ACTION);

ALTER TABLE `organization`.`employee`
ADD INDEX `idx_employee_organization` (`organizationId` ASC);
ALTER TABLE `organization`.`employee`
ADD CONSTRAINT `fk_employee_organization`
FOREIGN KEY (`organizationId`)
REFERENCES `organization`.`organization` (`id`)
ON DELETE NO ACTION
ON UPDATE NO ACTION;

ALTER TABLE `organization`.`employee`
ADD INDEX `idx_employee_role` (`roleId` ASC);
ALTER TABLE `organization`.`employee`
ADD CONSTRAINT `fk_employee_role`
FOREIGN KEY (`roleId`)
REFERENCES `organization`.`role` (`id`)
ON DELETE NO ACTION
ON UPDATE NO ACTION;

ALTER TABLE `organization`.`employee`
ADD INDEX `idx_employee_creator` (`createdBy` ASC);
ALTER TABLE `organization`.`employee`
ADD CONSTRAINT `fk_employee_creator`
FOREIGN KEY (`createdBy`)
REFERENCES `organization`.`user` (`id`)
ON DELETE NO ACTION
ON UPDATE NO ACTION;

ALTER TABLE `organization`.`employee`
ADD INDEX `idx_employee_modifier` (`updatedBy` ASC);
ALTER TABLE `organization`.`employee`
ADD CONSTRAINT `fk_employee_modifier`
FOREIGN KEY (`updatedBy`)
REFERENCES `organization`.`user` (`id`)
ON DELETE NO ACTION
ON UPDATE NO ACTION;

Резюме

В този урок обсъдихме дизайна на база данни на система за управление на служители за съхраняване на ролите, разрешенията, потребителите, организациите и управлението на служителите в организацията.

Можете да изпратите вашите коментари, за да се присъедините към дискусията. Може също да се интересувате от проектирането на базата данни на приложенията за блог, количка и анкета и анкета. Пълната схема на базата данни е достъпна и на GitHub.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Изберете MySQL база данни на Linux чрез командния ред

  2. Ръководство за проектиране на база данни за анкети и анкети в MySQL

  3. Търсене със стойност, разделена със запетая, mysql

  4. конвертирайте php дата във формат mysql

  5. Използване на Python dict за SQL INSERT израз